JavaScript is a very forgiving language. It’s easy to write code that runs but has mistakes in it.
In this article, we’ll look at things that we shouldn’t be putting in our code.
We Shouldn’t Put Assignment Operators in Conditional Statements
We shouldn’t put assignment operators in conditional assignments. For example, the following is probably a mistake:
if (title = "manager") {
}
The code above sets the title to 'manager' instead of checking if title has the value 'manager' . It’s probably a mistake since most people want to check the value with the === operator rather than doing an assignment operation in the if statement.
What we actually want is:
if (title === "manager") {
}
We Shouldn’t Leave Console in Production Code
console.log and other console methods are very useful for debugging our code. However, before we put them into production, we should have them removed so we aren’t exposing anything to the user unintentionally.
Therefore, the following code shouldn’t be in production code:
console.log("hello.");
console.warn("warning.");
console.error("error.");
Other console method calls also shouldn’t be committed. The only exception to this is when we use console to output data to the user in Node.js apps.
Then we may want to ignore this rule.
We Shouldn’t Put Constant Expressions in Conditions
Constant expressions are most likely a mistake unless we’re doing it intentionally. For instance:
if (false) {
foo();
}
The code above never runs since the condition inside is always false .
Also, when constant conditions are used in loops, we may get infinite loops or loops that never run. For example, the following is an infinite loop:
while (true) {
foo();
}
We probably don’t want that in most cases. If the condition in ternary expressions is constant, then it’s pretty useless since it always returns one value.
For instance:
let result = true ? 'foo' : 'bar';
Then result is always 'foo' since the condition is true , so the first value will always be returned.
Examples of code that make more sense include:
while (true) {
foo();
if (conditionFalse()){
break;
}
}
Putting Control Characters in JavaScript Regular Expressions
Control characters are in ASCII range 0 to 31. They’re special, invisible characters. These characters are rarely used in JavaScript strings so it’s probably a mistake.
For instance, the following is probably not what we want:
`const pattern1 =` /\x00/;
`const pattern2 = new RegExp("\x00");`
It’s very rare that we want to match the null character, which is character 0 in ASCII.
We Shouldn’t Put debugger Statements in Production Code
As its name suggests, debugger is used for debugging. It pauses the program in that line so that we can inspect the items in the current point in the code.
Also, there’re better ways to debug code that with debugger . Production code definitely shouldn’t have debugger in it because it pauses the program that the user is using if it’s present.
For instance, the following is a mistake:
const isTrue = (x) => {
debugger;
return x === true;
}
In production code, we should write:
const isTrue = (x) => {
return x === true;
}
We Should Never have Duplicate Arguments in Functions
Having the multiple parameters with the same means that the last occurrence of the parameter taking on the value of the last parameter with the same name.
For example, if we have:
const foo = (a, b, a) => {
console.log(a);
}
Then when we call foo as follows:
foo(1, 2, 3);
We see the value 3 logged. This causes confusion and it’s probably a mistake. It doesn’t make much sense to have 2 parameters with the same name.
Instead, we should rename the 3rd parameter:
const foo = (a, b, c) => {
console.log(a);
}
or remove the second a :
const foo = (a, b) => {
console.log(a);
}
Conclusion
There’re many kinds of mistakes that can be made when writing JavaScript code because of its forgiving nature. We should never leave debugging code like console or debugger . The only exception is when we use console to output values to users in Node apps.
Constant expressions in conditions are most likely to be mistaken. In conditional statements, we write code that always runs or never runs.
If they’re in loops, then they either create an infinite loop or one that never runs.
In ternary expressions, we create one that always assigns the same value. Therefore, it’s most likely not very useful and it’s a mistake.
Finally, we shouldn’t have duplicate parameter names in functions. It causes confusion since the last value that’s passed in overwrites the first one that’s assigned to the same parameter name.
